Why

Three faults observed live tonight, all the same class: an exception escaping into a consumer's await foreach ends that subscription for the rest of the process, so the feature it drives goes silently dead until the bot restarts. The outer try/catch around each loop reads as defensive, but it logs once and exits.

Same failure class as #63, which fixed it for one connection loop only.

1. Map connection-status loop faulted. InvalidOperationException: GetMap returned no data.

ConnectionSupervisor.GetMonumentsAsync forwarded the connection-level call (documented "Throws on failure") straight through a query seam whose own contract promised "or an empty list". It was the only query in RustPlusSocketSource without a degrade-to-null/empty catch, so a transient Rust+ error reached MapComposer and killed the map's status loop — no repaint on connect, no cache clear on disconnect, for the rest of the run.

It now catches, logs and returns [], and the failure message names the Rust+ error code (rate_limit, no_map, …) instead of a bare "returned no data".

2. ConnectionStatusChanged consumer faulted. TimeoutException (Discord REST)

A routine RequestBucket.EnterAsync timeout during a workspace reconcile killed the Workspace consumer, leaving the info channels stale. The code documented this as acceptable ("the reconciler is idempotent and a restart heals") — but a Discord timeout is ordinary traffic, not an exceptional event.

3. The same shape existed, unguarded, in 21 consumer loops across 11 services

Their relay handlers post to Discord and had no internal try/catch, so one REST timeout would permanently silence that feature.

What

New EventBusConsumption.ConsumeAsync<TEvent>(handler, onHandlerFailure, ct): subscribes, guards each handler call, reports failures and keeps consuming. Only cancellation of the loop token ends the subscription. RustPlusBot.Abstractions stays dependency-free — the callback is Action<Exception>, so each service keeps its own logger.

Every vulnerable consumer routes through it — Workspace (4), Alarms (6), Switches (6), StorageMonitors (5), Events (3), Map (3), Chat (2), Connections (2), Wipes (2), Players (1), InfoMap (1). Each service's outer try/catch stays as a backstop for a genuinely broken subscription.

ClansHostedService and CommandsHostedService are left alone deliberately: they already isolate per event inline, and Clans' failure log carries guild/server ids the shared callback can't reach.

Also

Rust+ sends the token apartmentcomplex, which no entry in MonumentTokenMap mapped, so apartment complexes rendered with no icon (No monument icon for token "apartmentcomplex" (mapped type: null)). MonumentType.ApartmentsComplex and Apartments_Complex.svg were already in RustMapsApi.Assets — only the token table hadn't caught up.

Tests

• EventBusConsumptionTests — a failing handler costs its own event only; cancellation still ends the subscription.
• WorkspaceConsumerResilienceTests and MapHostedServiceTests — both written failing first, reproducing the live exceptions (calls: 1 before the fix).
• A monuments-seam case in ServerQueryTests (failed with the exact production exception) and an apartmentcomplex case in MonumentTokenMapTests.

dtk dtk dotnet test RustPlusBot.slnx → 1253 passed, 1 skipped, 19 projects.

Not addressed

Why Discord's request bucket timed out, and why GetMap failed 3s after connect (three heavy GetMap round-trips land back-to-back on the connect path — plausible rate-limiting). This PR makes both survivable and self-describing; the new log lines will name the cause next time.

🤖 Generated with Claude Code